Another possible alternative: a method on the Drain type like fn keep_remaining(self) that consumes it without removing the as-yet-uniterated elements. (Sample implementation for Vec in https://internals.rust-lang.org/t/pre-rfc-lazy-drain-and-self-exhausting-iterators/7037/8?u=scottmcm)

This RFC came up when the libs team discussed the unstable drain_filter method rust-lang/rust#43244 and the consensus was to not stabilize more drain-like methods at the moment.

We’d like to see experimentation to attempt to generalize into a smaller API surface various combinations of draining:

• A sub-range (through RangeArgument a.k.a. RangeBounds) v.s. the entire collection (though the latter could be achieved by passing .., a value of type RangeFull).
• Draining everything (possibly within that range) v.s. only elements that match a boolean predicate
• Self-exhausting on drop v.s. not (leaving the rest of the elements in the collection).

Possibilities might include "overloading" a method by making it generic, or a builder pattern.

(One constraint is that the drain method is stable. It can possibly be generalized, but only in backward-compatible ways.)

This would likely be in a new RFC rather than taking this one as-is:

@rfcbot fcp postpone

Team member @SimonSapin has proposed to postpone this. The next step is review by the rest of the tagged teams:

• @Kimundi
• @SimonSapin
• @alexcrichton
• @aturon
• @dtolnay
• @sfackler
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

🔔 This is now entering its final comment period, as per the review above. 🔔

The final comment period is now complete.

This RFC is now postponed per the review above.

Thanks to @Emerentius!